1. Field of the Invention
The present invention relates to a bus bridge that relays data between two buses, and in particular relates to a method of arbitrating for ownership of a bus in delayed transactions.
2. Prior Art
A computer system is constituted by a variety of devices including a CPU (Central Processing Unit). In general, these devices are connected to data transfer routes called buses. This being so, bus bridges are typically employed to establish data transfers between buses of different standards and to expand buses. These bus bridges enable a computer system with a plurality of buses to be implemented.
A conventional bus bridge is explained below, by referring to FIG. 11.
(Construction)
FIG. 11 shows a construction of a conventional bus bridge 3, together with two buses 1 and 2 that are connected to the bus bridge 3.
The bus 1 is a VL-Bus (VESA (Video Electronics Standards Association) Local Bus). A CPU 12 and a memory 13 are connected to the bus 1.
The bus 2 is a PCI (Peripheral Component Interconnect) bus. A bus master 8, a bus master 9, and a target 10 are connected to the bus 2. A bus master referred to here is a device that can request ownership (i.e., right of use) of a bus from an arbiter. When the arbiter grants the request, the bus master initiates a bus cycle on the bus to communicate with a target device.
The bus bridge 3 performs delayed transactions in relaying data between the buses 1 and 2. A delayed transaction is a transaction in which a bus bridge issues a retry to a bus cycle initiated on a bus by a bus master rather than completing it immediately, so as to free the bus for other transactions until it becomes ready to provide read data to the bus master or accept write data from the bus master. A specific operation of such a delayed transaction is explained in greater detail later.
The bus bridge 3 is roughly made up of a bus interface 4, a bus interface 5, a buffer 6, and an arbiter 7. An arbiter 11 is connected with the bus bridge 3.
The bus interface 4 operates as an interface to the bus 1.
The bus interface 5 operates as an interface to the bus 2.
The buffer 6 is a memory for temporarily storing read data in delayed transactions.
The arbiter 7 has a function of arbitrating for ownership of the bus 2. The arbiter 7 is connected with the bus master 8 via a request signal line 14 and a grant signal line 15. The arbiter 7 is also connected with the bus master 9 via a request signal line 16 and a grant signal line 17. The arbiter 7 is further connected with the bus interface 5 via a request signal line 18 and a grant signal line 19, within the bus bridge 3. This being so, among the devices connected to the bus 2, the bus master 8, the bus master 9, and the bus interface 5 that are connected with the arbiter 7 can request ownership of the bus 2.
Here, a bus master or a bus interface asserts its request signal line to request ownership of the bus 2, and deasserts the request signal line to withdraw the request.
When two or more devices simultaneously request ownership of the bus 2, the arbiter 7 grants ownership to a device with a highest level of arbitration priority, based on a round-robin priority scheme. Here, the arbiter 7 grants ownership to the device by asserting its grant signal line.
Upon detecting the assertion of the grant signal line, the device acknowledges that ownership has been granted. Hence the device occupies the bus 2 and initiates a bus cycle.
Even if no device requests ownership of the bus 2, the arbiter 7 grants ownership to one of the devices connected to the bus 2 to keep the bus 2 driven, so as to prevent floating of the bus 2. This is called bus parking. Usually, the last device that occupied the bus 2 performs bus parking.
The arbiter 11 has a function of arbitrating for ownership of the bus 1. The arbiter 11 uses the same priority scheme as the arbiter 7. The arbiter 11 is connected with the CPU 12 via a request signal line 22 and a grant signal line 23. The arbiter 11 is also connected with the bus interface 4 via a request signal line 20 and a grant signal line 21. This being so, among the devices connected to the bus 1, the CPU 12 and the bus interface 4 that are connected with the arbiter 11 can request ownership of the bus 1.
(Delayed Transaction)
A delayed transaction performed by the bus bridge 3 is explained below, using an example when the bus master 8 reads data stored in the memory 13.
First, the bus master 8 requests ownership of the bus 2 by asserting the request signal line 14.
Upon detecting the assertion of the request signal line 14, the arbiter 7 performs arbitration. If the arbiter 7 determines the bus master 8 as the owner of the bus 2 as a result of the arbitration, the arbiter 7 asserts the grant signal line 15.
Upon detecting the assertion of the grant signal line 15, the bus master 8 initiates a read cycle to read data stored in the memory 13, on the bus 2.
The bus interface 5 detects an address of the data to be read, during an address phase of the read cycle. The bus interface 5 issues a retry during a data phase of the read cycle. The bus interface 5 also requests the bus interface 4 to initiate a read cycle on the bus 1 to read the data from the detected address.
The bus master 8 receives the retry during the data phase of the read cycle, and responsively deasserts the request signal line 14.
At this time, if another bus master connected to the bus 2 is requesting ownership of the bus 2 by asserting its request signal line, the arbiter 7 deasserts the grant signal line 15 of the bus master 8 and asserts a grant signal line of the other bus master.
If no bus master is requesting ownership of the bus 2, on the other hand, the arbiter 7 keeps the grant signal line 15 of the bus master 8 asserted.
Upon receiving the request to initiate the read cycle from the bus interface 5, the bus interface 4 asserts the request signal line 20. If the arbiter 11 asserts the grant signal line 21 in response, that is, if the arbiter 11 grants ownership of the bus 1 to the bus interface 4, the bus interface 4 immediately initiates the read cycle on the bus 1 to read the data from the memory 13. The read data is stored into the buffer 6.
The bus master 8 reasserts the request signal line 14, a predetermined period after the receipt of the retry. The arbiter 7 responsively performs arbitration. If the arbiter 7 determines the bus master 8 as the owner of the bus 2 as a result of the arbitration, the arbiter 7 asserts the grant signal line 15. Upon detecting the assertion of the grant signal line 15, the bus master 8 reinitiates a read cycle that is the same as before, on the bus 2.
The bus interface 5 detects the read cycle reinitiated by the bus master 8 on the bus 2, and transfers the data stored in the buffer 6 to the bus master 8 via the bus 2 during a data phase of the read cycle.
This is a typical delayed transaction.
In the above delayed transaction, the conventional bus bridge 3 may encounter the following problems.
The bus master 8 reasserts the request signal line 14 the predetermined period after receiving the retry. As a result of arbitration, however, the arbiter 7 may not immediately grant ownership to the bus master 8 but instead grant ownership to another bus master.
Also, even if the arbiter 7 immediately grants ownership to the bus master 8 and the bus master 8 reinitiates the read cycle on the bus 2, the data may not yet be stored in the buffer 6. This occurs when, for instance, a device connected to the bus 1 is occupying the bus 1 and therefore the bus interface 4 cannot obtain ownership of the bus 1 to read the data from the memory 13.
If the data is not stored in the buffer 6, the bus interface 5 issues a retry to the bus master 8 again. Thus, a premature reattempt to read the data by the bus master 8 may be repeated until the data is stored into the buffer 6. This causes significant inefficiency, as another bus master seeking access to the bus 2 cannot use the bus 2 during such vain read cycles performed by the bus master 8.
This problem may be overcome by a delay transaction arbitration technique disclosed in U.S. Pat. No. 6,199,131. According to this technique, an arbiter performs arbitration in the following manner. If a delayed read transaction of a bus master is pending, i.e., if the bus master receives a retry, the arbiter lowers a level of arbitration priority provided to that bus master. Once the delayed read transaction is completed, the arbiter raises the arbitration priority of the bus master to a highest level.
In this way, a bus master which receives a retry in a delayed read transaction is kept from repeatedly reinitiating a read cycle vainly. Also, the bus master can read desired data smoothly.
However, just lowering the level of arbitration priority of the bus master receiving the retry does not completely prevent the occurrence of a vain read cycle. If no other device is requesting ownership when the bus master requests ownership the predetermined period after receiving the retry, the arbiter does not have any choice other than that bus master in determining the owner of the bus. Accordingly, the arbiter grants ownership to the bus master, even when the data is not yet available. This causes the bus master to reinitiate a read cycle in vain.
Besides, if another device requests ownership one clock after the request of the bus master in this circumstance, that device has to wait until the vain read cycle of the bus master ends.
Also, the arbiter raises the arbitration priority of the bus master to the highest level once the data has become available. However, if another device is occupying the bus at this time, the bus master has to wait until that device releases the bus.